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AMENDMENTS TO THE SPECIFICATION: 

Please amend the paragraph beginning at page 2, line 5, and continuing to page 

2, line 12, as follows: 

In IP (Internet Protocol) access networks that support host mobility, the routing paths between the 
host and the network may change frequently and rapidly. For example. Mobile IP networks allow a 
mobile node or an entire moving network to change the access router that provides the first IP layer hop 
seen from the mobile node or from a moving network's edge. When the mobile node changes access 
router (due to, for instance, mobility), there is a need to establish a new path, whose nodes should ideally 
provide similar treatment to the IP packets as was provided along the old routing path. 

Please amend the paragraph beginning at page 2, line 27, and continuing to page 

3, line 5, as follows: 

A possibility is to simply move all the context from one access router AR to the other access 
router of a selected access point after handover. Said mechanism works properly when handling single IP 
flows. However, drawbacks have been recognized concerning services and sessions wherein more than 
one flow is involved. For example, Multimedia sessions may involve e<-several parallel IP flows, one for 
voice, one for video, and one for whiteboard. After a hand-over between two access points, it is not 
unusual that IP flows belonging to the same session are distributed on different radio interfaces of a 
terminal. In such a situation, the flows of a session are distributed on two access routers after the hand- 
over and associated context transfer. The context transfer must then be performed in both access routers, 
since there is no master access router that can assume responsibility for the session context. This would 
lead to a context synchronization problem since the session context may have to be renegotiated during a 
session. For example, the bandwidth of the session may be renegotiated. 
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Please amend the paragraphs beginning at page 4, line 11, and continuing to page 
4, line 19, as follows: 

One object with the technology disclosed herei n inv e ntion is to offer a coordination 
mechanism for the handling of context associated to flows that belong to the same session. 

In simple terms, the-a_problem addressed by ^ bat-the technology disclosed 

hereii i current inv e ntion addr e so e G is to define a context transfer procedure that meets 

the above requirements^ and #^an object of the technoloay disclosed herein p res e nt 
inv e ntion is to provide a solution to the stated problem. 

Please amend the paragraph beginning at page 4, line 22, and continuing to page 

4, line 24, as follows: 

The-A^problem is solved according to the technology disclosed herein p resent 

inv e ntion by a procedure coordinating the transfer of context that is specific for each 
flow with the transfer of context that is common for all flows. 

On page 4, last line, delete the following paragraph: 
Pr e f e rr e d e mbodimento are oet forth in th e d e p e nding claims. 

Please amend the paragraph beginning at page 5, line 1, and continuing to page 

5, line 2, as follows: 

An advantage with of the technolouy disclosed herein present invention is that it enables 
session-oriented IP-flow control in multi-access networks. 

Please amend the paragraph beginning at page 5, line 28, and continuing to page 

5, line 31, as follows: 

Figure 2a is a flow chart showing a first part of the method according to fee-an 
example embodimen t inv e ntion . The flow chart continues in figure 2b. 

Figure 2b is a flow chart showing a second part of the method according to the 
inv e ntion example embodiment . The flow chart starts in figure 2a. 
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Please amend the caption on page 5, line 34, as follows: 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Please amend the paragraph beginning at page 5, line 35, and continuing to page 

6, line 23, as follows: 

Figure 1 is a schematic block diagram illustrating a network system according 
to a preferred example embodiment of th e inv e ntion . In the figure is illustrated 

Internet protocol (IP) flow paths over a number of domains Dl-Dn between two end 
user terminals UTA, UTB. Said IP information flow is passing a number of 
middleboxes MB. Each domaiin comprises one Midcom Agent MA controlling at least 
one associated middlebox MB. The middleboxes are associated to router nodes that is 
routing the flow of data packets in accordance with their IP address. The IP flow is 
generated by one of the user terminals during an end-to-end session. The middleboxes 
MB store context data for each IP session flow. Once the middleboxes MB within a 
domain D receive context data, they establish and store the associated context. As 
user data packets arrive at the middleboxes MB of a domaun D, the respective 
middlebox MB associate these packets with their proper context and provide them 
with appropriate context dependent service. Such context dependent service is specific 
to the respective middlebox MB. A middlebox MB has means for controlling its 
operation and function. It also comprises means for hsindling context, e.g. reading, 
sorting, selecting, deleting, writing, storing, etc. A middlebox has also means for 
communicating with its associated Midcom Agent by means of one or more suitable 
protocols. Further, a middlebox comprises means for communicating with other 

middleboxes by means of one or more suitable protocol. According to the technok^av 
disclosed herein this inv e ntion , the Middleboxes are provided with means for storing 

22, i.e. a data storage, dynamic context. The middleboxes can be implemented by 
means of computer software program comprising coded instructions, when said 
computer program software is stored in a computer usable medium and run in a 
computer or processing meams, such as e.g. a server unit, a microprocessor, PC, data 
processing unit, CPU, etc. 
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Please amend the paragraph beginning at page 6, line 32, and continuing to page 
7, line 8, as follows: 

When a user terminal UT starts a session, it starts signalling along the end-to-end path UTA-UTB 
in order for the context, e.g. session related context, to get established in the middleboxes MB along the 
path UTA-UTB. That is, in all middleboxes MB[[,JJ that the user session data is going to traverse, the 
proper QoS, security or other context needs to be established and configured. The user terminals UT use a 
session layer, e.g. SIP/SDP (Session Initiation Protocol/Session Description Protocol), and/or an IP level 
signalling protocol, that supports the establishment and manipulation of arbitrary state information along 
the path of the IP flow. Such IP level stateful multi-domain protocol that is being standardized by the 
IETF is the group of protocols termed Next Steps in Signalling (NSIS) (see reference [7]). The NSIS 

protocol family is therefore the preferred IP level signalling protocol of the technology disclosed 

hercin p rescnt invention . 

Please amend the paragraph beginning at page 7, line 19, and continuing to page 
7, line 31, as follows: 

A Midcom Agent MA has means for controlling its operation and function. It also comprises 
means for handling context, e.g. reading, sorting, selecting, deleting, writing, storing, etc. Midcom Agent 
MA has also means for communicating with its associated middleboxes MBs by means of one or more 
suitable protocols. Further, a Midcom Agent MA comprises means for communicating with other 
Midcom Agents MAs by means of one or more suitable protocol over a control plane. According to the td 

technology disclosed hcrei nt his invention , the Midcom Agents are provided with Context Dividers 
CD for dividing the total context for a session consisting of multiple IP flows and means for storing 20, 
i.e. a data storage, common context. The Midcom Agent MA can be implemented by means of computer 
software program comprising coded instructions, when said computer program software is stored in a 
computer usable medium and run in a computer or processing means, such as e.g. a server unit, a 



microprocessor, PC, data processing unit, CPU, etc. 
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Please amend the paragraph beginning at page 8, line 1 7, and continuing to page 

8, line 34, as follows: 

A situation is illustrated in figure 111,11 wherein the User Terminal UTA is 
moving towards the access point AP2. If the terminal UPA is measuring the received 
signal strength from the surrounding base stations BS, the User Terminail UTA may 
find it necessary to perform a handover to the base station BS2 in AP2, as the signal 
strength from BSl (associated with API) becomes weaker than from BS2. The 
movement is therefore causing a layer 2 {L2) trigger in the terminal resulting in a 
hauidover to BS2 £ind AP2. Three positions 1, 2 and 3 for the moving user terminal 
UTA is given in figure 1 . The terminals UTA and UTB are involved in a multimedia 
session wherein three separate IP flows F1,F2,F3 (for example one for voice, one for 
video, and one for whiteboard ) are progressing simultaneously. ForOf different 
reasons, said separate IP flows may be connected to different access points of the 
network structure. In the first position, all these IP flows F1,F2,F3 may be connected 
to access point API. When the terminsd has moved to the second position, only one of 
the separate IP flows, Fl, is connected to API, and the other two IP flows F2,F3 are 

« 

connected to access point AP2. In position 3, when the terminal is somewhere between 
AP2 and access point AP, the two IP flows F2,F3 that where connected to AP2 in 
position 2 are still connected to AP2, but the IP flow Fl is transferred to access point 
AP3, which belongs to another domain, D2. 

Please amend the paragraphs beginning at page P, line 4, and continuing to page 

10, line 5, as follows: 

According to the technology disclosed herein inv e ntion . the Midcom Agents 
comprise a context divider function. At session initiation, one of the User terminals 
starts signalling along the end-to-end path in order for the context to get established. 
The context divider divides the total context according to a predetermined schedule 
into one common context and one dynaimic context per IP flow. The common context is 
stored within the Midcom Agent, but the specific dynamic context data is distributed 
to that middlebox to which the special IP flow, to which the specific dynamic flow 
belongs, passes. The means for dividing the totad context, context divider CD, for a 
session consisting of multiple IP flows in the Midcom Agents MA divides the context 
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into two types of contexts. The first type is called the common context and includes 
information elements that are common for all flows in the session. Moreover, the 
common context includes such information about each flow in the session that is 
permanent over the lifetime of the session, or cane am be renegotiated using e.g. 
session layer signalling. Examples of common context are session identity, flow 
identity suid allocated bandwidth for each flow in the session. The second type of 
context is called dynamic context. This context is defined for each flow and is updated 
frequently during a session. Examples of dynamic contexts are state information for IP 
header compression and packet schedulers. Further, dynamic context is related to 
events in the data path, such as the transmission or reception of a packet, and should 
therefore be processed in nodes along the data path, such as routers or middleboxes. 
On the other hand, common contexts are related to signalling events and should 
therefore be located in nodes that process session or IP layer signalling, such as a 
Midcom Agent. 

The requirements on the context transfer mechanism at hand-over are different for the 
two types of context, which will now be illustrated by means of figure 2, which is a 

flow chart of a preferred example embodimen t of the inv e ntion . The first step, step 

100, is performed when a session between user terminads is initiated and the data 
packet flows arrives to the access routers of the access points: 

- dividing the totad context associated to a session into common context, 

which is common to all flows of the session, and one dynamic context 

per data packet flow of the session (step 100). 

Please amend the paragraph beginning at page 13, line 6, and continuing to page 
13, line 7, as follows: 

The technology disclosed herein inv e ntion also relates to a Midcom Agent for 
haindling context of data packet flows in a network system according to claims 9 — 1#. 



-7- 



1463556 



